MuleSoft Accelerator for Healthcare

Automate the prior authorization process for more immediate authorizations, leading to better outcomes and increased satisfaction for patients, providers, and payers.

Overview

Prior authorizations are a key pain point for healthcare providers as they work to best serve their patients and provide them the services they need, in a reasonable timeframe, to improve care outcomes. Often, before a procedure or new clinician referral can occur, a prior authorization needs to occur to ensure insurance coverage. These can be lengthy, fraught with one-off errors, and lead to frustration for a patient or member, provider, and healthcare payer alike, not to mention adversely affecting patient care.

This particular use case automates the prior authorization process for more immediate authorizations, leading to better outcomes and increased satisfaction for patients, providers, and payers.

Glossary

Prior Authorization functional view

Prior Authorization use case diagram

Prior Authorization use case details

Prior authorization is an administrative process used in healthcare for providers to request approval from payers to provide a medical service, prescription, or supply. This process takes place before a service is rendered.

Is PA required?

Initiation of prior authorization will occur as part of a workflow that includes verification of payer coverage and determination that prior authorization is required using the Coverage Requirements Discovery (CRD) implementation guide and can be accomplished using CDS Hooks.

Gather PA information

The Documentation Templates and Rules (DTR) implementation guide enables the EHR to retrieve relevant payer documentation rules in computable form as well as associated FHIR questionnaires to support the assembly of information for a prior authorization claim. The provider can use the resulting automated process to assemble the required documentation to support the prior authorization request. As well, DTR enables the EHR system or a launched SMART on FHIR application to retrieve information from the patient’s record that is necessary to support the prior authorization request.

Prior Authorization Submission

The primary interaction supported by this implementation is submitting a prior authorization request and receiving back a response. To perform this, a 'Prior Authorization Support Request Bundle' resource is constructed by the client system. That bundle will contain the Patient, Claim, Coverage, Insurer Organization, Requestor Organization, and Practitioner resources along with various other resources for request items like ServiceRequest, MedicationRequest, or DeviceRequest needed to submit the PAS request in ASC X12 N 278 format.

This request bundle will be sent to the Mule API Claim/$submit endpoint, which will transform to X12 278 and X12 275 (if there are attachments) and eventually to the target system. The Mule API will receive the response and convert it into a response FHIR bundle containing ClaimResponse, Organization, Patient, and Coverage resources.

Prior Authorization Inquiry

The prior authorization inquiry is used for polling for pending authorization responses. This operation accepts Prior Authorization Support Inquiry Request Bundle and responds with Prior Authorization Support Inquiry Response Bundle with the results of the inquiry contained in the Bundle.

Sequence diagram

The following diagram illustrates the sequence of processing prior authorization 'submit and inquiry' operations:

Workflow

Before you begin

The Getting Started with MuleSoft Accelerators guide provides general information on getting started with the accelerator components. This includes instructions on setting up your local workstation for configuring and deploying the applications.

1. Provider launches the EHR Portal.
2. Provider selects the patient and type of request and completes the required documentation to which prior authorization requirement must be verified.
3. Provider submits the prior authorization request to payer.

Goals

• Add support for CRD cds-services to identify the list of available CDS Hooks
• Add support for CRD order-select-crd and order-sign-crd CDS Hooks
• Add support for DTR questionnaire, questionnaireresponse, and task to retrieve the questionnaire template, which sends the response to the questionnaire template for the medical service where prior authorization is required
• Add support for PAS Submit and Inquiry operations to convert from FHIR to X12 message formats
• Add support for prior authorization complete/pending and inquiry response to convert from X12 to FHIR message formats.
• Provide capabilities to extend or modify the solution based on the customer X12 companion guide.

Assumptions and constraints

The following will be used to guide or constrain the solution design at a high level:

• The EHR portal should be capable of retrieving patients and request types before invoking the Mule CRD app to get the list of available CDS hooks and selecting order-select-crd CDS hook to get the required information.
• The EHR portal will support SMART on FHIR capabilities for the launch sequence before invoking the Mule DTR app to get the questionnaire in FHIR format.
• The EHR portal will create a FHIR request bundle before invoking the Mule app to transform the PAS Submit request and PAS Inquiry from FHIR to X12 message formats.
• Mule applications will mock the payer system by using in-memory derby database.

End-to-end scenarios

• The Provider’s EHR system will initiate the prior authorization workflow to identify the Coverage Requirements using CRD CDS-services followed by an order select CDS hook.
• The Provider’s EHR system can retrieve relevant payer documentation rules in computable form as well as associated FHIR questionnaires using DTR endpoints to support the assembly of information for a prior authorization.
• Prior Authorization Support requests will be initiated in the EHR system by invoking the Mule API to transform PAS request ($submit) from HL7 FHIR to X12 278 message format.
• The Prior Authorization Mule API also supports transforming a PAS Inquiry request from HL7 FHIR to X12 278i message format. This API has the capability to convert 'submit and inquiry' responses from X12 to a FHIR message format.

Downloadable assets

• CRD Clinical Decision Support System API | API Specification | Implementation Template
• DTR System API | API Specification | Implementation Template
• Prior Authorization System API | API Specification | Implementation Template

References

The following are links to related and supporting documentation:

• Da Vinci Prior Authorization Guide
• Da Vinci Reference Implementation
• X12 Product Guide

Demonstration

Interested to see these assets in action, check out this demo recording highlighting this use case!

---

back to top